\section{OpenFlow}
OpenFlow provides an open protocol to allow software applications to program the flow table of different switches. An OpenFlow switch consists of three main components: a flow table, a secure channel and a controller, as shown in Fig 1. The flow table is a list of flow entries. Each entry has match fields, counters and instructions, as shown in Fig 2. Incoming packets are compared with the match fields of each entry and if there is a match, the packet is processed according to the action contained by that entry. Counters are used to keep statistic information about packets. The packet can also be encapsulated and sent to the controller.
\paragraph{•}
Fig 1: OpenFlow based network
\paragraph{}
The controller is software based and it is responsible for manipulating the switch's flow table, using the OpenFlow protocol. The secure channel is the interface that connects the controller to all switches. Through this channel, the controller manages the switches, receives packets from the switches and sends packets to the switches. The details of the OpenFlow protocol are available in the OpenFlow 1.1 specification document [OpenFlowSpec1.1]. Version 1.2 was released in December 2011 and it is available at [OpenFlowSpec1.2]. However, version 1.1 is still the one that is mostly used. (More reading required to give details of the differences)
\paragraph{•}
Fig 2: Fields of a flow entry in the flow table 
\paragraph{}
In order to run applications on top of the controllers to manipulate the flow table of a switch, a network operating system is required. It acts as an intermediate layer between the OpenFlow switch and the user application. The network operating system communicates with the switch using the OpenFlow protocol and notifies the application of network events. The most commonly used network operating systems for OpenFlow are Nox [Nox], Beacon[Beacon] and Maestro[Maestro].

Using OpenFlow, experimental and production traffic can share the same OpenFlow switch. The action of a flow table entry of an OpenFlow switch can be to send the packet to the switch data path. On the other hand, a different flow entry can be defined for experimental traffic. This way, experimental traffic can be tested without interfering with the production traffic [OpenFlow]. In order to further enhance this, Sherwood et al. proposed FlowVisor [FlowVisor]. Using this technique, it is possible for several controllers to share the control of a switch. A centralized OpenFlow based controller ``slices'' the network and acts as an intermediate layer between the switch and all the OpenFlow controllers that manipulate the switch.

In the next Section we will describe the main capabilities of OpenFlow and how they are being exploited in different applications.
